Test instruments were originally compact stand-alone devices that performed physical measurements and displayed the results. For example, an oscilloscope measured the voltage as a function of time at a particular point in a circuit and displayed the result as a simple graph of voltage versus time. As the cost of computational hardware decreased, additional capabilities were incorporated into test instruments to provide increased computational and display capabilities. This new class of instruments typically includes a general-purpose computer that performs various calculations on the raw data or configuration parameters and provides more sophisticated data output capabilities including enhanced displays.
One class of test instruments is organized into three layers. At the lowest layer are the modules that actually generate the signals that are applied to the device under test (DUT) and measure signals received from that device. This layer will be referred to as the “physics” layer in the following discussion. These devices include RF signal generators, A/D and D/A converters, frequency converters, signal conditioners, digital signal processors (DSPs) and gate arrays. Many of these devices include software components that can be utilized to control the operation of the modules by appropriate calls to routines within the software. In some cases, the software itself can be augmented to provide new functions. The specific modules utilized in a particular instrument are sometimes provided by a vendor that is different from the vendor that provides the test instrument. Hence, the software at the module level can be more or less independent of the specific test instrument in which the module resides.
The second layer of software typically includes programs that transform the physical measurements provided by the physics layer into the basic measurements of interest. This layer of software will be referred to as the measurement layer in the following discussion. For example, a network analyzer typically measures the response of a DUT to an RF signal as a function of the frequency of the RF signal. The analyzer may include the RF signal generator, a local oscillator (LO) generator, and a mixer that down converts a signal received from the DUT to a base band determined by the LO signal. Finally the analyzer measures the amplitude and phase of the signal from the mixer as a function of frequency by causing the RF signal generator and LO generator to sweep through the desired range of frequency values. The measurement layer software controls the physics layer modules and software such that the modules generate the correct signals. The measurement layer software converts the raw measurements from the modules into the measurements of interest, i.e., the amplitude and phase of the signal from the DUT as a function of frequency.
The measurement layer routines are preferably independent of the specific modules that are used to generate and measure the signals that provide the final measurement. The lifetime of any particular module is limited, and hence, systems that can be altered by the replacement or addition of a new module without the need to rewrite a significant portion of the measurement layer routines have distinct advantages in terms of the cost of designing and maintaining a family of test instruments. Furthermore, a particular measurement layer application set may be useable in a number of different instruments based on different sets of physics level modules. Hence, to provide the desired level of independence, an application program interface (API) is provided between the physics layer and the measurement layer routines. This API provides a number of standardized calls that can be utilized by the measurement level software to operate the physics level devices and software. When a module is altered, at most, the API calls that interact with that module need to be updated.
The third major layer will be referred to as the presentation layer in the following discussion. Many of the tests that are performed using a test instrument involve making a number of different measurements and then combining data from the different measurements to arrive at the quantity of interest. For example, a network analyzer is often used to characterize a DUT in terms of the S parameters that characterize that DUT. To arrive at values for each S parameter as a function of frequency, the response of the DUT must be measured as a function of frequency as well as the response of the system with the DUT replaced by certain calibration devices. The results obtained with the calibration devices are then combined with the results obtained with the DUT to arrive at the S parameters. The software in the measurement layer performs this type of computation and utilizes the presentation layer to display or transmit the results in a manner that is more useful to the user than the measurements provided by the measurement layer routines.
The software in the presentation layer is preferably constructed such that the presentation software does not depend on a detailed knowledge of the function calls, algorithmic sequences and specific calculations, and organization of the software in the measurement layer. This allows the presentation software to be used with a variety of instrumentation platforms without having to substantially modify the software when moving from platform to platform. In addition, third party software can be more easily adapted for use in the presentation layer if this level of independence is maintained. To provide the desired level of independence, a second application program interface (API) is provided between the presentation layer and the measurement layer routines. This API provides a number of standardized calls that can be utilized by the presentation level software to access and control the measurement level software.
In some situations, it would be advantageous for third parties to have access to the APIs discussed above to facilitate the development of additional software that can be run on a given instrument. In other situations, it would be advantageous for third parties to substitute their software for pre-existing default measurement software. In addition, it would also be advantageous to control the level of access given to outsiders with respect to the APIs so that separate charges could be made for accessing particular features. However, the APIs discussed above are often proprietary to a particular instrument manufacturer and may include trade secrets or other proprietary information that the manufacturer does not wish to reveal to outsiders. Also, the APIs discussed above may vary between the product lines of a manufacturer. In addition, the APIs do not provide a method for limiting a user to a particular subset of the function calls in the API. Hence, many of the advantages of allowing third parties to have access to the APIs have not been fully realized.